В свете недавней истории хочется перефразировать известную пословицу: «Плохому программисту ОС и компилятор мешают». Неопытные программисты и админы регулярно присылают сюда истории своих глупостей, которые сами воспринимают как правильные действия. Обычно это скорее забавно, чем раздражает. Но вот когда количество глупостей на историю зашкаливает, а самоуверенность толкает очередного д’Артаньяна на огульное обвинение куда более умных людей, возникает желание поставить наглеца на место, а заодно предостеречь других новичков от его ошибок. Не стыдно чего-то не знать: все мы были новичками. Стыдно не пытаться осознать свои ошибки, а обвинять в них других. Итак, разберём по косточкам все дурости.

Использование хеш-функции для сравнения. Хеши хороши, чтобы сократить время сравнения в случае множества объектов. Например, если нужно проверить, совпадает ли новая матрица с тысячей уже имеющихся. Важно помнить, что сравнение хешей только убирает заведомо ложные варианты, но их совпадение не означает идентичности исходных объектов. Причина называется умным словом «коллизия». Так что после проверки по хешу нужно всегда проводить проверку полную, иначе будем получать неприятные трудноуловимые ошибки. То есть для исходной задачи сравнения всего двух матриц хеши не подходят от слова «совсем».

Выбор детерминанта на роль хеш-функции. У меня даже слов не хватает, чтобы выразить всю глупость этого. Во-первых, это очень дорогая в вычислительном плане функция, причём с неприятным ростом количества вычислений от размера матрицы. Лобовая реализация имеет факториальную зависимость, а через метод Гаусса «всего лишь» кубическую. Во-вторых, очень подвержена коллизиям, причём как раз на наиболее вероятных причинах модификации исходной матрицы. Например определитель транспонированной матрицы всегда равен определителю исходной.

Применение операции == для вещественных чисел. Новички, объяснять все причины долго, так что запомните как аксиому: операцию == можно применять только к целым числам, а вещественные всегда сравниваются путём вычисления их разницы и проверки, что она по модулю меньше определённого порога.

Незнание об автоматическом приведении типов в используемом языке (скорее всего, C). Функция det() может возвращать значение не double, а более ёмкого типа, который компилятор приводит в double при присвоении в double и, наоборот, до которого расширит double при сравнении. С учётом этого факта никаких странностей в приведённом коде нет вообще — всё вполне логично. Перед тем как кидаться с обвинениями в адрес разработчиков компилятора, стоило открыть определение функции det() и посмотреть на тип результата, потом внимательно почитать описание стандарта языка программирования и сравнить реализацию на соответствие; наконец, почитать описание компилятора на тему особенностей реализации на той или иной аппаратной платформе и возможных отклонений от стандартов.

Морали в этой истории две.

Первая: не выпендривайтесь с применением того, что вы толком не понимаете. Вместо ускорения вы можете получить торможение, а задачу при этом так и не решите.

Вторая: когда сталкиваетесь со странным поведением кода, всегда ищите проблему с мыслью «а не дурак ли я?». Это куда чаще оказывается правильным, чем поиск с мыслью «где-то налажали разработчики компилятора и ОС». Не то чтобы их пишут непогрешимые — это не так, ошибки в них действительно встречаются. Но это происходит значительно реже, чем ошибки начинающих и даже опытных программистов в их собственном коде.